Capybara summary for PR 1824

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2025-05-06T21:06-04:00 d73beba}}

Just to check though, is this creating new Trajectories which point to the data in the two input collections?

If the factory doesn't own the new trajectory, what does?

Good point.

Just to check though, is this creating new Trajectories which point to the data in the two input collections?
If the factory doesn't own the new trajectory, what does?

Good point.

The reason why I introduced this data ownership policy was to address memory issues that I had attributed to duplicate deletes due to storing the same track pointers in multiple ActsExamples::Trajectories. That's why I had naively made it non-owning, since I assume what was happening was that the ActsExamples::Trajectories destructor that deleted the tracks.

It turned out to be a different problem entirely: insufficient clearing of the pointer vectors in JOmniFactory (cc @nathanwbrei: sometimes the std::vector<T*> has non-zero size when entering Process). After fixing that, there is no more need for the data ownership policy boolean, or the underlying functionality in JOmniFactory.